fix: Include 'module' import condition in resolve.conditions #525

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Merged

justinvdm merged 1 commit into main from investigate-tslib

Jun 17, 2025

Collaborator

justinvdm commented Jun 17, 2025 •

edited

Loading

Change

Adds module import specifier to the resolve.conditions for all three environments (ssr, worker, client).

Context

ShadCN users were running into this issue:

TypeError: Cannot destructure property '__extends' of 'import_tslib.default' as it is undefined.

This appears to happen because:

tslib has various import specifiers, including
- one that maps node import specifier to a wrapper that module that imports its cjs build, and reexports it as an esm via a default export (code)
- one that maps module import specifier to an esm module (code)
- Since fix: Support packages with only node import condition and no workerd condition #510, we added a node import condition to the worker and ssr import conditions, meaning it would resolve to tslibs esm wrapper around its cjs build
- This would be fine, except esbuild adds a wrapper to convert the cjs build to an esm build
- Since tslib's own esm wrapper imports the default import for the cjs build, it doesn't get the named exports created by esbuild's wrapper

Links


          fix: Include 'module' import condition in resolve.conditions

97ca6f7

justinvdm merged commit 1feff0d into main

5 checks passed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet